![[AWS] Site to Site VPN の BGP 経路を制御しよう](https://devio2023-media.developers.io/wp-content/uploads/2019/05/amazon-vpc.png)
[AWS] Site to Site VPN の BGP 経路を制御しよう
こんにちは、菊池です。
AWSとオンプレミスの拠点を接続するSite to Site VPNやDirectConnectでは、経路情報を交換/制御するために動的ルーティングプロトコルのBGPを使用します。このBGPの経路交換ですが、経験がないとなかなかイメージがつかみにくく、また、オンプレ側の機器も必要なので検証も気軽にやりにくいところがあります。今回は、BGP経路情報がどのように広報され、経路制御されるのか、Site to Site VPNのいくつかのパターンで実際に試してみましたので、紹介します。
基本的な仕様
具体的な設定の前に、基本的な仕様の確認です。Site to Site VPNのルーティング仕様については以下のドキュメントに記載されています。（英語版の方がより詳細です）
Site to Site VPNおよびDirectConnectで、重複するルートが存在する場合にはVirtual Private Gateway（VGW）は以下の優先順位でルートを決定します。
- ロンゲストマッチ（宛先ネットワークがより詳細に絞り込まれているルート）
- DirectConnectとSite to Site VPNではDirectConnectが優先
- Site to Site VPNで静的ルートとBGPルートでは、静的ルートが優先
- BGPルートの中ではAS PASHが最短のものが優先
- AS PATHが同じ場合はMEDが最小のものが優先
Transit Gatewayについては記載がないため、実際に検証して試していきたいと思います。
なお、Customer Gateway（CGW）にはCisco C841Mを使用して検証しています。
Virtual Private Gateway との VPN接続
まずは基本となるVirtual Private Gatewayとの接続です。以下、オンプレ側ネットワークを10.10.10.0/24、AS番号を65000、AWS側のVPC CIDRを172.16.0.0/16、AS番号を64512固定で検証しています。
VPN接続を1つ作成すると、上記の図のようにAWS側には2つのVPN接続エンドポイントが作成され、2つのIPSecトンネルを作成します。また、BGPも各トンネルで設定されてルートを交換します。このときのBGPテーブルを確認すると以下のようになります。
#show ip bgp
BGP table version is 3, local router ID is 192.168.1.253
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.0/24 0.0.0.0 0 32768 i
* 172.16.0.0 169.254.248.61 200 0 64512 i
*> 169.254.210.217 100 0 64512 i
宛先ネットワーク172.16.0.0/16に対しては2つのBGPルートを受信し、そのうちNest Hopが169.254.210.217の経路がベストパス（最適経路： > が表示されている）として選出されています。これは、Nest Hop：169.254.210.217の経路がMetric（MED）が100と最小になっているためです。
この結果、採用されたベストパスが以下のようにルートテーブルに記載されます。
#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 192.168.1.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 192.168.1.1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.0/24 is directly connected, Vlan1
L 10.10.10.254/32 is directly connected, Vlan1
169.254.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 169.254.210.216/30 is directly connected, Tunnel1
L 169.254.210.218/32 is directly connected, Tunnel1
C 169.254.248.60/30 is directly connected, Tunnel2
L 169.254.248.62/32 is directly connected, Tunnel2
B 172.16.0.0/16 [20/100] via 169.254.210.217, 00:00:38
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, GigabitEthernet0/5
L 192.168.1.253/32 is directly connected, GigabitEthernet0/5
このように、VGWとのVPN接続では、AWS側から明示的に通知されるMEDによって、優先経路が設定されるようになっています。
Transit Gateway との VPN 接続
続いて、Transit GatewayとのSite to Site VPN接続を確認します。
Transit Gatewayの場合、複数のVPN接続をロードバランスするECMP（Equal Cost Maltipath：等コストパルチパス）ルーティングのサポートが設定可能です。ECMPはTransit Gateway単位（VPN接続単位ではない）での有効/無効設定となり、作成後に変更はできませんので注意が必要です。
ECMP 無効の場合
まずはECMPを無効にしたTransit Gatewayでの確認です。
VGWと同様、1つのVPN接続（アタッチメント）を作成することで2つのIPSec VPNトンネル、BGPセッションが作成されます。
#sho ip bgp
BGP table version is 3, local router ID is 192.168.1.253
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.0/24 0.0.0.0 0 32768 i
* 172.16.0.0 169.254.249.245 100 0 64512 e
*> 169.254.28.53 100 0 64512 e
先ほどのVGWの場合と異なり、172.16.0.0宛ての2つの経路はどちらもMetric（MED）が100で同じになっています。BGPのパス属性は同じですが、Next Hop：169.254.28.53宛ての経路（図のTunnel1）がベストパスに選択され、以下のようにルートテーブルに記載されています。
#sho ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 192.168.1.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 192.168.1.1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.0/24 is directly connected, Vlan1
L 10.10.10.254/32 is directly connected, Vlan1
169.254.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 169.254.28.52/30 is directly connected, Tunnel1
L 169.254.28.54/32 is directly connected, Tunnel1
C 169.254.249.244/30 is directly connected, Tunnel2
L 169.254.249.246/32 is directly connected, Tunnel2
B 172.16.0.0/16 [20/100] via 169.254.28.53, 00:00:34
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, GigabitEthernet0/5
L 192.168.1.253/32 is directly connected, GigabitEthernet0/5
ベストパスにNext Hop：169.254.28.53の経路（図のTunnel1）が選択された理由ですが、Ciscoルータの場合にはBGPパス属性が同じルートの場合には先に学習したルートが選択されるためです。以下のように、BGPネイバーの状態を確認すると、169.254.28.53が先にアップしていることがわかります。
#show ip bgp summary BGP router identifier 192.168.1.253, local AS number 65000 BGP table version is 3, main routing table version 3 2 network entries using 288 bytes of memory 3 path entries using 240 bytes of memory 2/2 BGP path/bestpath attribute entries using 320 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 872 total bytes of memory BGP activity 2/0 prefixes, 3/0 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 169.254.28.53 4 64512 5 6 2 0 0 00:00:17 1 169.254.249.245 4 64512 4 3 2 0 0 00:00:07 1
CGW側はTunnel1をベストパスに選出したことがわかりました。一方で、Transit Gateway側はどうでしょうか。Transit Gatewayでのルーティングの状態はTransit Gatewayルートテーブルにて確認することができます。
こちらと、VPN接続の状態を確認することで、どの経路が選択されているかわかります。
Transit Gateway側もTunnel1を優先経路に採用していることがわかりました。しかし、この状態だと、CGWはたまたま先にアップしたTunnel1を優先経路に採用しており、Transit Gateway側はどういうアルゴリズムで採用されたのか不明です。
そのため、CGW側でBGPパス属性を調整することで、明示的に優先ルートを指定できるように設定していきたいと思います。Transit GatewayではBGPパス属性を設定することはできませんので、いずれもCGW側で可能なパラメータを調整することで実現します。
- CGW側：AS PATH プリペンドを使用
- Transit Gateway側：WEIGHT属性を使用
AS PATH属性は経路情報がどのASを経由してきたかを示すパラメータで、経由してきたAS番号をリストで持ちます。AS PATHはBGPで必須の属性情報で、AWSでもサポートされます。AS PATHプリペンドでは、AS番号のリストに自信のAS番号を複数追記することで、対向のルータに対して経由するASを多く見せることができます。
WEIGHT属性はCISCO独自のもので、BGPのベストパス選定で最初に（最優先で）利用されます。外部への経路通知には利用されませんが、ルーター内部でどのBGPネイバーから受信した経路を優先するかを明示的に指定します。
実際の設定は以下のようにやってみます。まずは、AS PATHプリペンドのためのルートマップを作成します。これで、10.10.10.0/24の経路を広報する際に、AS番号65000, 65000を追加で付与します。
ip prefix-list PRE-AS permit 10.10.10.0/24 route-map R-ASPRE permit 10 match ip address prefix-list PRE-AS set as-path prepend 65000 65000 route-map R-ASPRE permit 20
そして、AS PATHプリペンドの適用するネイバーをTunnel1側に設定します。また、Tunnel1側のWEIGHTを100、Tunnel2側のWEIGHTを200設定します。WEIGHTは大きい方が優先されます。
router bgp 65000 bgp log-neighbor-changes neighbor 169.254.28.53 remote-as 64512 neighbor 169.254.28.53 timers 10 30 30 neighbor 169.254.249.245 remote-as 64512 neighbor 169.254.249.245 timers 10 30 30 address-family ipv4 network 10.10.10.0 mask 255.255.255.0 neighbor 169.254.28.53 activate neighbor 169.254.28.53 weight 100 neighbor 169.254.28.53 soft-reconfiguration inbound neighbor 169.254.28.53 route-map R-ASPRE out neighbor 169.254.249.245 activate neighbor 169.254.249.245 weight 200 neighbor 169.254.249.245 soft-reconfiguration inbound exit-address-family
これを整理すると、下記の図のようになります。同じ経路情報を受け取った際にCGWは、WEIGHTの大きいTunnel2をベストパスに選出します。一方で、Transit GatewayはAS PATHを比較しますが、Tunnel1側にAS PATHプリペンドで追記したことで、Tunnel2側を最短経路として採用するようになります。
CGWのBGPテーブルを見ると、WEIGHTが大きい方のTunnel2であるNext Hop：169.254.249.254がベストパスに選出されています。
#show ip bgp
BGP table version is 3, local router ID is 192.168.1.253
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.0/24 0.0.0.0 0 32768 i
* 172.16.0.0 169.254.28.53 100 100 64512 e
*> 169.254.249.245 100 200 64512 e
ルートテーブルにも反映されます。
#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 192.168.1.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 192.168.1.1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.0/24 is directly connected, Vlan1
L 10.10.10.254/32 is directly connected, Vlan1
169.254.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 169.254.28.52/30 is directly connected, Tunnel1
L 169.254.28.54/32 is directly connected, Tunnel1
C 169.254.249.244/30 is directly connected, Tunnel2
L 169.254.249.246/32 is directly connected, Tunnel2
B 172.16.0.0/16 [20/100] via 169.254.249.245, 00:03:40
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, GigabitEthernet0/5
L 192.168.1.253/32 is directly connected, GigabitEthernet0/5
また、Transit Gateway側も、AS PATHプリペンドによって意図した経路選択がされていることが確認できます。
ECMP 有効の場合
続いて、Transit GatewayでECMPを有効にするケースです。1つのVPN接続では、最大で1.25Gbpsまでの帯域を利用可能ですが、それを超えるスループットが必要な場合にはECMPを有効にすることで複数のVPN接続をロードバランスすることが可能になります。ロードバランスを実現するためには、複数のVPNトンネルがルートテーブルに記載される必要がありますので、その設定を試していきます。
まずは、デフォルトの設定で接続します。この状態ではCGWは、ECMP無効のケースと同様に1つの接続がベストパスに選出されます。
#show ip bgp
BGP table version is 3, local router ID is 192.168.1.253
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.0/24 0.0.0.0 0 32768 i
* 172.16.0.0 169.254.181.201 100 0 64512 e
*> 169.254.206.41 100 0 64512 e
CGWのルートテーブルでも、1つの経路のみがルートテーブルに記載されています。
#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 192.168.1.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 192.168.1.1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.0/24 is directly connected, Vlan1
L 10.10.10.254/32 is directly connected, Vlan1
169.254.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 169.254.181.200/30 is directly connected, Tunnel2
L 169.254.181.202/32 is directly connected, Tunnel2
C 169.254.206.40/30 is directly connected, Tunnel1
L 169.254.206.42/32 is directly connected, Tunnel1
B 172.16.0.0/16 [20/100] via 169.254.206.41, 00:00:50
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, GigabitEthernet0/5
L 192.168.1.253/32 is directly connected, GigabitEthernet0/5
一方で、Transit Gateway側のルートテーブルには、2つの経路が有効になっています。
この状態だと、
- オンプレミス -> AWS方向のトラフィックは片方のVPN接続を利用
- AWS -> オンプレミス方向のトラフィックは2つのVPN接続を負荷分散
となってしまい、非対称ルーティングとなります。意図しない非対称ルーティングは通信トラブルの原因となりますので、避ける方が望ましいです。CGWがデフォルトでは1経路のみをベストパスとしてルートテーブルに記載するようになっていますので、複数経路を選定できるようにmaximam-pahtsを指定します。
router bgp 65000 bgp log-neighbor-changes neighbor 169.254.181.201 remote-as 64512 neighbor 169.254.181.201 timers 10 30 30 neighbor 169.254.206.41 remote-as 64512 neighbor 169.254.206.41 timers 10 30 30 address-family ipv4 network 10.10.10.0 mask 255.255.255.0 neighbor 169.254.181.201 activate neighbor 169.254.181.201 soft-reconfiguration inbound neighbor 169.254.206.41 activate neighbor 169.254.206.41 soft-reconfiguration inbound maximum-paths 2 exit-address-family
これで、BGPテーブルを確認すると、Tunnel2側もmultipathとして選出されていることがわかります。
#show ip bgp
BGP table version is 4, local router ID is 192.168.1.253
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.0/24 0.0.0.0 0 32768 i
*m 172.16.0.0 169.254.181.201 100 0 64512 e
*> 169.254.206.41 100 0 64512 e
ルートテーブルにも2つの経路が追加されました。
#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 192.168.1.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 192.168.1.1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.0/24 is directly connected, Vlan1
L 10.10.10.254/32 is directly connected, Vlan1
169.254.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 169.254.181.200/30 is directly connected, Tunnel2
L 169.254.181.202/32 is directly connected, Tunnel2
C 169.254.206.40/30 is directly connected, Tunnel1
L 169.254.206.42/32 is directly connected, Tunnel1
B 172.16.0.0/16 [20/100] via 169.254.206.41, 00:00:15
[20/100] via 169.254.181.201, 00:00:15
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, GigabitEthernet0/5
L 192.168.1.253/32 is directly connected, GigabitEthernet0/5
このように、同じ宛先情報・BGPパス属性であれば、Transit Gatewayでは複数経路のロードバランスが可能です。
ECMP 有効で複数の VPN 接続
さらに応用として、2つのVPNアタッチメント、4つのトンネルの場合もみてみます。
まず、2つのSite to Site VPN接続のTransit Gatewayアタッチメントを作成して、アップさせます。
すると、Transit Gatewayルートテーブルには4つの経路ができることが確認されます。
CGW側はmaximum-pathsを4に設定します。
router bgp 65000 bgp log-neighbor-changes neighbor 169.254.146.153 remote-as 64512 neighbor 169.254.146.153 timers 10 30 30 neighbor 169.254.181.201 remote-as 64512 neighbor 169.254.181.201 timers 10 30 30 neighbor 169.254.206.41 remote-as 64512 neighbor 169.254.206.41 timers 10 30 30 neighbor 169.254.235.141 remote-as 64512 neighbor 169.254.235.141 timers 10 30 30 address-family ipv4 network 10.10.10.0 mask 255.255.255.0 neighbor 169.254.146.153 activate neighbor 169.254.146.153 soft-reconfiguration inbound neighbor 169.254.181.201 activate neighbor 169.254.181.201 soft-reconfiguration inbound neighbor 169.254.206.41 activate neighbor 169.254.206.41 soft-reconfiguration inbound neighbor 169.254.235.141 activate neighbor 169.254.235.141 soft-reconfiguration inbound maximum-paths 4 exit-address-family
すると、4つの経路全てが選出され、
#show ip bgp
BGP table version is 6, local router ID is 192.168.1.253
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.0/24 0.0.0.0 0 32768 i
*m 172.16.0.0 169.254.146.153 100 0 64512 e
*m 169.254.235.141 100 0 64512 e
*m 169.254.181.201 100 0 64512 e
*> 169.254.206.41 100 0 64512 e
ルートテーブルにも4つの宛先経路が記載されます。
#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 192.168.1.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 192.168.1.1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.0/24 is directly connected, Vlan1
L 10.10.10.254/32 is directly connected, Vlan1
169.254.0.0/16 is variably subnetted, 8 subnets, 2 masks
C 169.254.146.152/30 is directly connected, Tunnel4
L 169.254.146.154/32 is directly connected, Tunnel4
C 169.254.181.200/30 is directly connected, Tunnel2
L 169.254.181.202/32 is directly connected, Tunnel2
C 169.254.206.40/30 is directly connected, Tunnel1
L 169.254.206.42/32 is directly connected, Tunnel1
C 169.254.235.140/30 is directly connected, Tunnel3
L 169.254.235.142/32 is directly connected, Tunnel3
B 172.16.0.0/16 [20/100] via 169.254.235.141, 00:00:55
[20/100] via 169.254.206.41, 00:00:55
[20/100] via 169.254.181.201, 00:00:55
[20/100] via 169.254.146.153, 00:00:55
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, GigabitEthernet0/5
L 192.168.1.253/32 is directly connected, GigabitEthernet0/5
複数のVPNアタッチメントでも同様にロードバランスが可能となります。
VGW と Transit Gateway が混在した VPN接続
最後に、ちょっと特殊なケースです。
1つのVPCに対して、VGWとTransit Gatewayの両方をアタッチします。そして、VGW、Transit Gatewayそれぞれから1つのCGWにトンネルを作成し、経路情報がどうなるかを確認します。
実際に受信した経路情報をBGPテーブルで確認してみると、以下のようになります。
#show ip bgp
BGP table version is 5, local router ID is 192.168.1.253
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.0/24 0.0.0.0 0 32768 i
* 172.16.0.0 169.254.248.61 200 0 64512 i
*> 169.254.210.217 100 0 64512 i
* 169.254.180.13 100 0 64512 e
* 169.254.213.81 100 0 64512 e
Next Hop：169.254.210.217の経路がベストパスに選出されています。172.16.0.0あての4つのルートのうち、上の2つがVGWから受信した経路、下の2つがTransit Gatewayから受信した経路です。VGWから受信した経路は、最初のケースと同様、Metric（MED）が小さい方が優先されます。
そして、VGWとTransit GatewayではORIGIN属性（Pathの64512の後ろのiまたはe）が異なっています。ORIGIN属性はBGPのメッセージに必ず含まれる項目で、ルートの生成元を示します。i（IGP）>e（EGP）>?（Incomplete）の順に優先されますので、iであるVGWから通知されるルートとして採用しています。なお、BGPのベストパス選出では、AS PATH > ORIGIN > MEDの順に優先度が決まりますので、先に紹介したAS PATHプリペンドを使えばどちらを優先するかのコントロールも可能です。
ルートテーブルには、ベストパスに選出された1つが記載されます。
#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 192.168.1.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 192.168.1.1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.0/24 is directly connected, Vlan1
L 10.10.10.254/32 is directly connected, Vlan1
169.254.0.0/16 is variably subnetted, 8 subnets, 2 masks
C 169.254.180.12/30 is directly connected, Tunnel1
L 169.254.180.14/32 is directly connected, Tunnel1
C 169.254.210.216/30 is directly connected, Tunnel3
L 169.254.210.218/32 is directly connected, Tunnel3
C 169.254.213.80/30 is directly connected, Tunnel2
L 169.254.213.82/32 is directly connected, Tunnel2
C 169.254.248.60/30 is directly connected, Tunnel4
L 169.254.248.62/32 is directly connected, Tunnel4
B 172.16.0.0/16 [20/100] via 169.254.210.217, 00:00:54
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, GigabitEthernet0/5
L 192.168.1.253/32 is directly connected, GigabitEthernet0/5
まとめると、以下のようになります。
まとめ
Site to Site VPNの経路制御を色々なパターンで試してみました。
なかなか実際に試すのが難しいこともあるかと思いますので、どこかでお役に立てれば幸いです。実際の環境では、オンプレミス側のネットワーク構成やCustomer Gatewayの仕様などにも依存しますので、しっかりと設計することが大切です。
![[レポート] VPC Lattice と PrivateLink を利用したクロス VPC リソースアクセス「Simplify cross-VPC resource access with PrivateLink and VPC Lattice」 #NET218](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
